在實際的企業場景裡，我們常常會遇到到底要使用哪些 AI 護欄的問題;大部分人想到的可能都是如何使用 SLM 或 LLM 來完成所謂的 AI 護欄。但以筆者的作為企業 IT 顧問的角度出發、應該是按照企業需要哪些功能或種類的 AI 護欄才達成基本的防護。
接下來的幾天，我會分別以以下幾個企業需要的常用 AI 護欄作為撰寫對象，包括：
假設有一份萬字的配送改善報告，前面都在整理物流流程、缺貨原因與處理建議，附錄卻留下這一句客服紀錄：
顧客林小安來電，電話0912-000-000，地址臺中市西屯區範例街8號；反映商品尚未送達，請客服查詢配送進度。
這是 Day 11 使用的一筆虛構資料。假設摘要任務不需要辨識顧客身分，政策也允許送出遮罩後的內容，那麼姓名、電話與地址應該移除，配送問題仍然值得保留。
一份文件只有這一句個資，對防護流程反而是個難題。整份擋掉，摘要工作就做不了；只找到其中一個電話，其他個資又可能跟著送出去。同樣一句個資放進越長的文件，其他可用內容就越多，也越值得精確處理那一小部分。
我認為，長文本 PII Guardrails 的設計應該從這個需求出發：讓原本有價值的內容繼續被使用，同時能交代送出前檢查了哪些文字、移除了哪些個資。 模型能接收多長的輸入、一次能跑多快，都要放回這個目標來判斷。
如果政策要求含個資的報告一律不得外送，找到一個禁止外送的實體，就可能足以阻擋。這時文件層級的判定有它的用途。
但要保留這份報告的大部分內容，防護流程就得知道姓名、電話、地址各自在哪裡。只回傳「有個資」，呼叫端仍然無從修改原文。這也是文件層級判定與實體層級偵測的差別：前者回答這份文件是否包含個資，後者提供可以採取處理的位置。
差別會直接影響我們怎麼看偵測結果。若只找到電話，文件層級的判定已經答對；對遮罩工作而言，姓名與地址卻仍然漏掉。拿「成功辨識含個資文件」當成「成功移除個資」，會讓結果看起來比實際完整。
Presidio Analyzer 的結果介面提供了一個具體例子：RecognizerResult 包含 entity_type、start、end 等欄位，讓後續處理知道實體類型與原文範圍；Anonymizer 再依這些範圍與處理設定修改文字。對遮罩流程來說，能把判斷接到原文位置，是選擇偵測介面時需要考慮的條件。
如果一個服務只提供整份文件的標籤，它仍然可以用來阻擋或決定是否轉交其他檢查。要靠它完成局部遮罩，就還缺少實體定位這一段能力。
長上下文（Long Context）讓整份文件一次送進模型成為可能，也減少了切塊與合併的工作。要依賴這種方式處理個資，還得確認全文是否真的送進去，以及目標資訊能否被找出來。
「萬字」不是模型輸入長度的精確單位。不同 tokenizer 對同一份中文文件可能有不同計數，請求裡還有系統指令與其他上下文。真正需要核對的是完整請求，以及送入偵測器的實際內容。若輸入已經被截斷，附錄根本沒有送進去，後面的遮罩流程再正確也無法處理它。
即使全文都送進去了，那一句出現的位置仍然值得關注。《Lost in the Middle》 在多文件問答與鍵值檢索任務中觀察到，相關資訊的位置會影響部分受測模型的表現，放在長上下文中間時可能較難取用。這讓我在評估長文本偵測能力時，會要求同一段已標註的個資出現在不同位置：開頭能找到，不足以代表中間與結尾也能找到。
這個判斷也要配合偵測方法。用正規表示式辨識完整電話，不涉及模型如何取用上下文；若漏掉，應先看輸入範圍、文字轉換與格式是否符合規則。姓名、語意指涉，或需要前後文才能辨識用途的數字，則更依賴偵測器看到的內容。
因此，選擇長上下文模型時，我會把「實際收到全文」與「能在全文中定位目標」分開看。前者是資料處理的責任，後者才是偵測能力的問題。兩者混在一起，就很容易把截斷造成的遺漏誤認為模型不夠好，或把請求成功誤認為全文已受到保護。
切塊（Chunking）能控制每次檢查的輸入大小，也讓較小的偵測器有機會處理長文件。但它會改變偵測器看到的內容。
若切點落在 0912-000-000 中間，兩塊各自只剩半個電話，原本能命中的格式就消失了。號碼即使完整保留，說明它用途的「電話」也可能留在上一塊。偵測器仍然看得到號碼，卻失去了辨識用途的線索。
依段落或句子切分，再用重疊區保留部分邊界內容，是可以考慮的處理方式。代價是同一段文字會被重複檢查，總處理量增加；而且固定長度的重疊，仍然未必涵蓋相隔很遠的語意線索。切塊大小應該依文件與偵測方法決定，不能只選一個順手的數字就視為問題已解決。
找到實體之後，還有另一個容易被低估的工作：把位置接回原文。
如果每一塊都是原文未修改的連續片段，局部位置加上該塊的起點，就能換算成全文位置。若切塊前整理了空白、移除換行，或在每塊前面補上標題，這個對應關係就可能改變。偵測器指出的位置，必須能回到準備遮罩的那一版文字；字元、UTF-8 位元組與 token 索引，也不能直接混用。
重疊區的同一個電話可能被找到兩次，必須依全文位置合併。某一塊逾時或未完成檢查，則代表全文仍有未檢查的部分，其他塊沒有命中不能填補這個缺口。至於要重試、轉交其他檢查或暫停外送，應由政策決定。
這些工作都會算進切塊方案的成本。小模型單次呼叫比較快，並不能直接推論整份報告處理得比較快；切塊、重疊、重試、結果合併與遮罩都在同一條路徑上。採用切塊，等於由防護流程承擔全文完整性的責任。
進入檢索增強生成（RAG）流程後，問題又會改變：模型可能只收到幾個檢索片段。
如果這次只要送出客服附錄中的一段文字，就可以針對那次請求的內容檢查與遮罩。但這個結果只適用於已檢查的片段，不能擴大成「整份報告沒有個資」。片段的來源、文件版本與後續組合，都會影響這個判斷能否沿用。
更早的資料流也要一起看。如果原文在建立索引時，就被送往外部 embedding 服務，等檢索完成才遮罩，已經無法保護那一次外送。防護要放在資料跨越權限邊界之前；索引與生成可能經過不同的服務，也就需要依各自的資料去向判斷。
回到開頭那份配送報告，我會用最後送出的內容來看這套設計是否達到目標：需要移除的姓名、電話與地址是否仍然存在，摘要所需的配送資訊是否保留下來，以及這份輸出對應的文字是否都完成了檢查。
完整檢查不保證偵測必然正確，所以還需要用已標註資料觀察漏掉哪些實體、誤處理哪些正常內容。不過，若連檢查範圍與輸出位置都接不起來，模型分數再高，也無法回答這份報告到底受到多少保護。
那份萬字報告仍然值得用來分析缺貨與配送問題。把不需要的姓名、電話與地址移除，保留能支持分析的內容，是這個情境下採用 PII Guardrails 的理由。長文本防護的設計，也應該沿著這個用途來選擇偵測方法、處理範圍與外送位置。
iThome鐵人賽
看影片追技術